home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19970104-19970326
/
000446_news@columbia.edu _Thu Mar 20 22:25:35 1997.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
6KB
Return-Path: <news@columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id WAA18981
for <kermit.misc@watsun.cc.columbia.edu>; Thu, 20 Mar 1997 22:25:34 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id WAA20814
for kermit.misc@watsun; Thu, 20 Mar 1997 22:25:33 -0500 (EST)
Path: news.columbia.edu!sol.ctr.columbia.edu!spool.mu.edu!uwm.edu!newsfeeds.sol.net!news.maxwell.syr.edu!cam-news-hub1.bbnplanet.com!su-news-hub1.bbnplanet.com!news.bbnplanet.com!newsout1.alt.net!news1.alt.net!news.aros.net!news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Problems with Tecra+DOS+kermit
Message-ID: <1997Mar20.194638.95771@cc.usu.edu>
Date: 20 Mar 97 19:46:37 MDT
References: <5gpdtl$718$1@argon.csl.sri.com>
Organization: Utah State University
Lines: 85
Xref: news.columbia.edu comp.protocols.kermit.misc:6778
In article <5gpdtl$718$1@argon.csl.sri.com>, rushby@news.csl.sri.com (John Rushby) writes:
> I have a Toshiba Tecra 740 booted to MSDOS via F8
> (I'm running DOS simply because Linux isn't installed yet).
I presume, being laptop-less in Logan (UT), that the Toshiba is
a distinguished member of the laptop tribe.
> There is an internal modem on COM2, standard address and IRQ, RTS flow
control.
And we presume that there is a serial port on COM1 so that there is
this second serial port of interest to Kermit. That is, COM1 is not an address
pair but rather the "first" of two such sought by the Bios at power on time.
We go on at length about this in the MSK release notes, in case some readers
wonder what I'm talking about.
> Kermit 3.14 is unable to use this modem with the speed set higher than 2400!
> I get the same problem with an external modem via COM1;
>
> However, if I disable the internal modem (via tsetup) and use a
> Megahertz PCMCIA modem as COM2 (using the point enabler), it works fine.
MegaHertz Inc has advertized that they try harder to overcome
PCMCIA compatibility issues, and maybe they succeeded on your machine.
> I've tried other versions of Kermit on the internal modem with the
> following results:
>
> 3.15: same problem as 3.14
> 3.13: doesn't even load--divide trap (does the same on my P6 desktop)
The divide by zero is very likely in the software timing loop
calibration procedure executed at port startup, which runs overboard on
fast machines. The problem was solved in MSK v3.14.
> 2.29: works perfectly!
You would have to say that. Hmmm.
> The symptom at higher speeds with 3.14 is that ATH generates 0 and
> then everything locks up. Dialing works but nothing appears on the
> screen. "Show modem" reports everything as expected. I know this
> sounds like the "can talk but cannot hear" problem described in
> kermit.bwr, but the address and IRQ are ok, there are no conflicts
> that I can see, and that wouldn't explain why 2.29 works, nor why 3.14
> works at slow speed and with a PCMCIA modem.
I'm real short on ideas, but let me try some anyway.
PCMCIA equipment is decidely peculiar and awfully specific to
individual laptops. Thus generalizing won't work, and some pairing
of equipment performs well and yet pairing of other reputable equipment
does not, for mysterious PCMCIA reasons. That's become common knowledge.
There are two parts to the higher speed business. One is talking
to the command interpreter in the modem to do AT stuff. The other is in
data transfer mode moving data bytes both ways. Behavior is sometimes
very different. The biggest problem is the command mode part, where there
really isn't a decent command interpreter in the modem and instead the
data pump silicon is coerced into parsing the AT stuff. When that occurs
we must speak v e r y s l o w l y to the modem or it loses track. By
slowly I mean less than four bytes per second. MSK has delay code to be
sluggish while initialzing a serial port for use, but there is no telling
how slow some modems need to be addressed and there is no added sluggishness
after the port has been started.
I hesitate to bring this up, but you have probably heard of these
"Windows modems" which are totally dependent on software in Windows to
perform operations above 2400 bps. The makers removed the guts of modern
modems, shaved a few bucks off the cost, and gave buyers a two piece unit
(hardware and necessary Windows software). If your modem is of this kind
there is nothing Kermit can do about the matter. We strongly recommend
against using such modems, for obvious reasons.
If dialing works but connections don't then we do have a classical
"talk but not listen" situation. The cause is there are no interrupts from
the serial port reaching Kermit telling it a character has arrived. I gather
that this isn't the case.
The apparent lockup after typing ATH is almost as if the machine
has put the modem hardware to sleep, perhaps not very gracefully. It does
say that while Kermit is in Connect mode behaving normally a reversion to
modem command mode is iffy and an ATH command leads the modem into never
never land (all the while Kermit is doing exactly the same processing steps).
Should the machine drastically change the hardware available upon an ATH then
Kermit's following attempts to talk to that serial hardware may fail in
unknown ways (what was valid hardware becomes a land mine).
As you can see, I'm guessing pretty wildly here, searching for
possibilities.
Joe D.